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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The present document is part 2 of a multi-part deliverable covering IP Datacast: Implementation Guidelines for 
Mobility, as identified below: 

Part 1 : "IP Datacast over DVB-H" ; 

Part 2: "IP Datacast over DVB-SH". 



Introduction 

IP Datacast over DVB-SH is an end-to-end broadcast system for delivery of any types of digital content and services 
using IP-based mechanisms optimized for devices with limitations on computational resources and battery. An inherent 
part of the IP Datacast system is that it comprises a unidirectional DVB broadcast path that MAY be combined with a 
bi-directional mobile/cellular interactivity path. IP Datacast is thus a platform that can be used for enabling the 
convergence of services from broadcast/media and telecommunications domains (e.g. mobile/cellular). 

DVB-SH is a waveform specification enabling hybrid satellite and terrestrial mobile reception to handheld terminals. It 
introduces a number of features improving reception performance (interleaving, turbo code, new modulation schemes in 
both TDM and OFDM modulations) and enables dual reception of satellite and terrestrial signal using a common 
framing. 

The present documents provides guidelines of IPDC mobility over DVB-SH network, and between DVB-H and 
DVB-SH networks in line with existing IPDC phase 1 mobility over DVB-H guidelines. To achieve this goal, the 
present document describes the SH constraints and scenarios using IPDC phase 1 mobility "toolbox" and wording. 
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The document is split into two main chapters: 

• First, the contextual background introduction is given in clause 4 with definitions, abbreviations and 
numbering of most important identifiers in a mobility context. 

• Then the description of handover DVB-SH scenarios in SFN and non SFN cases is given in clause 5; for each 
case, the actual list of handover is first introduced, then the actual procedure for achieving the handover from a 
terminal standpoint is given. A DVB-H to DVB-SH handover is given as a particular example. 
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Scope 



The present document presents contextual information on handover required in DVB-SH networks. Handover is 
considered as the procedure used within one IP platform in order to continue IP Datacast service consumption under 
specific network modifications. The present document relies on the DVB-SH (see [12], [13] and [i.7]) and IP Datacast 
phase 1 (see [2] to [8]) set of specifications. 

Roaming between IP platforms is not addressed by the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission System for Handheld 

Terminals (DVB-H)". 

[2] ETSI TS 102 468: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of 

Specifications for Phase 1". 

[3] ETSI TS 102 470-1: "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 1: IP Datacast over DVB-H". 

[4] ETSI TS 102 611-1: "Digital Video Broadcasting (DVB); IP Datacast: Implementation Guidelines 

for Mobility; Part 1: IP Datacast over DVB-H". 

[5] ETSI TS 102 47 1 : "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic 

Service Guide (ESG)". 

[6] ETSI TS 102 472: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content 

Delivery Protocols". 

[7] ETSI TS 102 474: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Service 

Purchase and Protection" . 

[8] ETSI TS 102 005: "Digital Video Broadcasting (DVB); Specification for the use of Video and 

Audio Coding in DVB services delivered directly over IP protocols". 
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[9] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information: Systems". 

[10] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[11] ETSI EN 301 192 (VI. 4.1): "Digital Video Broadcasting (DVB); DVB specification for data 

broadcasting". 

[12] ETSI TS 102 585: "Digital Video Broadcasting (DVB); System Specifications for Satellite 

services to Handheld devices (SH) below 3 GHz". 

[13] ETSI EN 302 583: "Digital Video Broadcasting (DVB); Framing Structure, channel coding and 

modulation for Satellite Services to Handheld devices (SH) below 3 GHz". 

[14] ETSI TS 102 470-2: "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 2: IP Datacast over DVB-SH". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] IEEE proceedings: "Loss-free handover for IP datacast over DVB-H networks"; Gunther May. 

[i.2] ETSI TR 102 377: "Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines". 

[i.3] ETSI TR 102 473: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Use Cases and 

Services". 

[i.4] ETSI TR 102 469: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Architecture". 

[i.5] ETSI TR 101 21 1: "Digital Video Broadcasting (DVB); Guidelines on implementation and usage 

of Service Information (SI)". 

[i.6] ETSI TR 101 162: "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) 

codes for DVB systems". 

[i.7] ETSI TR 102 584: "Digital Video Broadcasting (DVB); DVB-SH Implementation Guidelines". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

3.1.1 Bearer-related definitions 

multiplex: stream of all the digital data carrying one or more services within a single physical channel (characterized 
by parameters like carrier frequency and modulation modes) 

partially available Transport Stream (paTS): TS where the SDT (actual) contains service_availability descriptors; in 
the DVB-SH case, the hybrid_delivery_system_descriptor can signal the potential presence of such paTS in the non 
SFN case only 

section: syntactic structure used for mapping all services information into ISO/IEC 13818-1 [9] 

service: sequence of programmes under the control of a broadcaster which can be broadcast as part of a schedule 

signalling_field: plays the same role as the TPS in the TDM modulation scheme 
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sub table: comprised of a number of sections with the same value of table_id, table_id_extension and version_number 

table: comprised of a number of sections with the same value of table_id 

Transport Parameter Signalling (TPS): in the OFDM modulation scheme, represents the information signalled in the 
multiplex for easing the terminal determination of the multiplex radio configuration and ultimately the multiplex 
reception 

NOTE: In particular the modulation main parameters such as code rates, modulation scheme, interleaver, etc. are 
transmitted as parts of the TPS. Also the cell_id identifying the cell identifier is transmitted as part of the 
TPS. By reading these parameters that are sent with a pre-defined configuration, the terminal can quickly 
learn important information for reception and handover purposes. 

Transport Stream (TS): stream of transport_packets, as defined in ISO/IEC 13818-1 [9] 

3.1 .2 Infrastructure-related definitions 

Complementary Ground Component (CGC): set of DVB-SH terrestrial transmitters having the duty to repeat the 
satellite signal and optionally transmit selective terrestrial-only signal 

delivery system: physical medium by which one or more multiplexes are transmitted 

IP Encapsulator: equipment in charge of encapsulating an IP flow into MPEG2 transport stream according to [1 1] 

MFN network: network of transmitters that operate in different frequencies 

NOTE: They are usually fed by different IP encapsulators and transport different content but some content MAY 
be shared in order to ensure seamless hand-over. 

phase shifting: process of shifting in time the sending of burst between two adjacent IP encapsulators so that the 
handover can be made possible seamlessly, even for a mono-tuner receiver 

NOTE: A description of such a process is described in [i. 1]. 

Satellite Component (SC): set of DVB-SH terrestrial transmitters having the duty to send the satellite signal 

SFN mode: situation where transmitters are time synchronized to ensure coherent radio demodulation at OFDM symbol 
and exactly same bits transmission over the air, including signalling like cell_id 

SFN network: network of transmitters that operate in SFN mode 

NOTE: We distinguish between two cases: 

■ SFN over hybrid frequency: transmitters modulating on hybrid frequency are synchronized, 
including the SC and the CGC ones, over their cell of belonging (size is the size of the satellite cell, 
also called beam); 

■ SFN over terrestrial frequency: transmitters modulating on a non-hybrid frequency are 
synchronized over their cell of belonging (size can be as small as the coverage of one individual 
transmitter). 

transmitter: equipment in charge of modulating a TS according to DVB-SH or DVB-H specification 

NOTE: In the DVB-SH case, the transmitters MAY be of two kinds, those modulating a signal transmitted over a 
satellite cell (also called a beam) that are part of the SC, and those transmitting a signal over a terrestrial 
cell that are part of the CGC. 

transposer: equipment in charge of transposing a multiplex in another frequency; no demodulation/modulation is 
performed, only radio level operations are performed such as filtering, amplification, frequency shifting... 
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3.1.3 Geographical-related definitions 



cell: geographical area that is covered with DVB-H or DVB-SH signals delivering one or more particular transport 
streams throughout the area by means of one or more transmitters 

NOTE: In the DVB-SH case, a cell MAY have continental or nationwide extension if this TS is sent over the 
hybrid frequency - in this case it is also called a beam - or local extension if this TS is sent over the 
non-hybrid frequency. The cell is uniquely identified with the cell_id whose scope depends if this is 
DVB-H or DVB-SH network. 

sub-cell: geographical area that is part of the cells coverage area and that is covered with DVB-SH signals by means of 
a transposer 

NOTE: In this case, no remodulation of the signal is performed. 

3.1 .4 DVB Network-related definitions 

DVB network: collection of MPEG-2 Transport Streams, each carried in a multiplex, and transmitted on a single 
delivery system 

NOTE: DVB network is identified by network_id. 

IP platform: set of IP flows managed by an organization 

NOTE: The IP platform represents a harmonized IP address space that has no address collisions. An IP platform 
MAY span several Transport Streams within one or more DVB networks. Several IP platforms MAY 
co-exist in the same Transport Stream. IP platform is identified by platform_id. IP platform is usually 
used as a selector of the service provider but this is not an absolute rule and one service provider could 
use several IP platforms simultaneously. 

Program Service information (PSI): digital data describing the DVB programs present in the TS and ways to find 
their identifier inside the TS (PID) 

NOTE: Examples are PMT and PAT. 

Service information (SI): digital data describing the delivery system, content and scheduling/timing of broadcast data 
streams, etc. 

NOTE: Examples are NIT, SDT, INT. The NIT describes the network configuration, in particular the modulation 
parameters, the cells, their frequencies, etc. . . The hybrid_delivery_system_descriptor is in charge of 
giving the modulation parameters. The NIT is also used as a selector to know if the terminal has to 
perform paTS processing. If this is the case, the SDT gives details on the present DVB services. 

3.1.5 Content-related definitions 

content removal: technique used to enable content localization on the hybrid frequency 

NOTE: The principle is that (DVB-H) time-sliced services are mapped on DVB services by the service injection 
point (IP encapsulator). The actual "virtual" larger TS having all DVB service is sent as is to all 
transmitters (including satellite and terrestrial) that individually process the TS to remove the non relevant 
DVB services by ad-hoc TS level processing. This process and its impact on PSI/SI is described in [14]. 
At reception side, the terminal can always make the link between the content and IP addresses via ESG, 
IP addresses and global path via the INT, DVB service availability and cells via the SDT and actual 
cell_id signalled via the TPS and finally global path and PID via PAT/PMT. 

DVB-SH service: defined in [13], this is a fraction of a TS signalled via the SH-IP (SH Initialization Packet) to the 
modulator 

NOTE: The SH service is used to perform synchronization and mapping between the service layer (e.g. DVB-H) 
and the physical layer in order to ease content removal process in specific conditions (see [14]). The 
DVB-SH service is of no interest for the terminal and has only an infrastructure scoping. 

Global Content (GC): content sent over the satellite beam which constitutes a nation-wide cell and repeated by a CGC 
over local cells; in SH-A SFN, GC is always a complete TS but in non SFN it can be a partially available TS 
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Hybrid Frequency (HF): part of the frequency plan that is used to transport the GC 

NOTE: HF transports GC but can additionally transport LC in non SFN case. 

IP flow: flow of IP datagrams each sharing the same IP source and destination address 

NOTE: An IP flow is identified within an IP platform by its source and destination addresses. IP flows on 

different IP platforms may have the same source/destination addresses, but are considered different IP 
flows. IP flows may be delivered over one or more IP streams. 

IP stream: physical mapping of an IP Flow to transport_stream_id, original_network_id, service_id, component_tag, 
and IP source/destination addresses 

NOTE: An IP stream is delivered on an MPE section stream. 

Local Content (LC): complete or part of the transport stream that is sent over one or several terrestrial cells of the 
CGC 

NOTE: Depending on infrastructure choices and radio planning, it MAY be a full TS or a partially available TS. 

Non Hybrid Frequency (NHF): part of the frequency plan that is specifically not used to transport any GC 

NOTE: NHF transports only LC. 

service availability: characteristic of a DVB service to be present only in a fraction of the cells rather than all the cells 
where the TS is actually transmitted (see clause 6.2.33 in [10], clause 4.2.3.12 in [i.5] and also [14]); this enables to 
deliver a common SI shared by different TS/multiplexes, the terminal having the duty to identify the localization, id-est 
the binding between service and cell_id 

NOTE: The concept of service availability is heavily used for managing all local content in non SFN 
configurations. 

3.1.6 Business-related definitions 

Electronic Service Guide (ESG): defined in [5], this is a set of standard IP flows giving semantic information on the 
programmes currently or in the near future available on actual TS 

Service Provider (SP): owner of the service application as defined in [i.4], it generates its own ESG as well as its own 
ECM/EMM 

Service Purchase and Protection (SPP): defined in [7], it defines the signalling required to protect the content sent 
over the broadcast medium 

NOTE: This includes authentication of the user, credential checking, purchase processing, etc. 

3.1 .7 Terminal-related definitions 

hand-over: process of achieving seamless (without any interruption) transition between two IP streams instantiating the 
same IP flow 

NOTE: These IP streams MAY be located to different DVB networks, original or not, cell or sub-cell, multiplex, 
transport stream, same or different DVB services, but they usually (but this is not a strong requirement, 
only a best practise case) belong to the same IP platform and to the same service provider. Hand-over 
does not require re-processing of ESG nor SPP. Although theoretically possible, handover between two 
different IP platforms is not considered in the present document. 

roaming: process of transitioning between two IP streams providing the same or related content that are distributed by 
different SP having contracted roaming agreement 

NOTE: This induces a possible - but not necessarily - change of IP flow, potentially belonging to different IP 

platforms. This involves a change of service provider in the form of an ESG and/or SPP provider. We can 
cite the case of roaming within the same IP platform (between two service providers providing the same 
service) or IP platform roaming (different service provider providing same service over two IP platforms). 
Seamless roaming is usually not possible. Roaming is not considered in the present document. 
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zapping: process of transitioning between two different IP flows, potentially belonging to different IP platforms 
NOTE: So they MAY carry different content stream. Zapping is not considered in the present document. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



CBMS 


Convergence of Broadcast and Mobile Services 


CGC 


Complementary Ground Component 


DVB 


Digital Video Broadcasting 


DVB-H 


DVB-Handheld [1] 


DVB-SH 


DVB Satellite to Handheld devices [12] 


ESG 


Electronic Service Guide [5] 


GC 


Global Content 


HF 


Hybrid Frequency 


ID 


check 


INT 


check 


IP 


check 


IPDC 


IP Datacast 


IPE 


IP Encapsulator 


LC 


Local Content 


MFN 


Multi Frequency Network 


NHF 


Non Hybrid Frequency 


NIT 


check 


NW 


Network 


OFDM 


check 


PAT 


check 


paTS 


partially available TS 


PID 


check 


PMT 


check 


PSI 


Program Service information 


SC 


Satellite Component 


SDT 


check 


SF 


Signalling Field 


SFN 


Single Frequency Network 


SH 


check 


SH-IP 


SH Initialization Packet 


SI 


check 


SP 


Service Provider 


SPP 


Service and Purchase Protection 


TDM 


check 


TPS 


Transport Parameter Signalling 


TS 


Transport Stream 



Background 



The focus of the present clause is to provide a brief introduction on PSI/SI tables, ESG and descriptors used in IPDC in 
DVB-SH Systems. 
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4.1 



Overview 



A DVB network is uniquely identified by a network_id. A DVB network consists of one or more Transport Streams, 
each being transmitted by one or more DVB signals. All emitting sites (cell_ids) of a network do not need to transmit 
all TSs of the network or all the DVB services part of present TS. Information about a DVB network is available within 
the NIT sub_table (identified by network_id). The NIT lists all TSs and DVB signals available within the DVB 
network. The NIT is carried within each Transport Stream in a DVB network and the NIT is unique throughout the 
network. Since there MAY be several adjacent networks, there MAY be several NITs. The network which the TS 
belongs to is described by NIT(actual) whereas other networks are described by NIT(other). 

The INT identifies for each IP stream what are the 5-uplet required for its identification {network_id, 
original_network_id; transport_stream_id; DVB service_id; component_tag}. The number of DVB services per TS 
depends on the chosen configuration: 

• for SFN configuration, the number of DVB service is usually limited to 1. Each service session that is time 
sliced is announced in the INT and the receiver can derive from the component tag the corresponding 
matching PID via the PSI tables (PAT and PMT); 

• for non SFN configurations, the DVB service MAY be more than 1, in order to differentiate between their 
location. The service location information is delivered via the SI tables using SDT table together with DVB 
service_id and service_availability descriptor (see [14]). 



DVB networks 



Transport Streams 



DVB services 



Elementary Streams 



Multiplex 1 

ID: transport_stream_id 4 

original_network_id 

PS l/SI: PAT 



DVB service 1 
ID: service_id 
PSI/SI: PMT 



Component 1 
ID:component_tag, PID 




Multiplex 2 

ID: transport_stream_id 4 

original_network_id 

PSI/SI: PAT 



DVB service 2 
ID: service_id 
PSI/SI: PMT 



Component 2 
ID: componentjag, PID 



Multiplex 3 

ID: transport_stream_id h 

original_network_id 

PSI/SI: PAT 




DVB service 2 
ID: service_id 
PSI/SI: PMT 




Component 3 
ID: componentjag, PID 



Figure 1 : Services ID hierarchy with DVB-SH 

An IP flow is a flow of IP datagrams, each sharing the same IP source and destination addresses enabling identification 
of the flow within the IP range managed by the IP platform. An IP flow belongs to exactly one IP platform. An IP 
stream represents an instantiation of such an IP flow defined by the 5-uplet {transport_stream_id, original_network_id, 
network_id, service_id, and component_tag}. 

Note that an IP stream MAY be announced by multiple INT sub_tables within the same TS, possibly making it part of 
multiple IP platforms. In such a case some coordination is required between IP platforms. This case is not considered in 
the present document. 
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IP platform 



IP platform 1 
ID: platformjd 
PSI/SI: INT 



IP flow 



IP flow 1 
ID: IP address 




IP flow 2 
ID: IP address 



IP stream 




IP stream 1 

ID: transport_stream_id+ 

original_network_id+ 

component tag 



IP flow 3 
ID: IP address 



IP stream 2 

ID: transport_stream_id+ 

original_network_id+ 

componenMag 



IP stream 3 

ID: transport_stream_id+ 
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Figure 2: IP ID hierarchy 



4.2 Network ID and original network ID 

In DVB, the original_network_id is defined as the network_id of the network where the TS originated. 

For terrestrial DVB the concept of an original network, with an original_network_id, could be interpreted as a sort of 
abstract hypothetical network feeding all real networks (in the sense of network_id) in e.g. a country. The 
original_network_ids are typically allocated by DVB on a per-country basis and enable to identify unambiguously the 
source of the TS on a worldwide basis among the 65 535 possible sources. On the contrary, network_ids are used by 
local physical networks to identify a local infrastructure that conveys the TS. So the network_id has a local scope and 
values could be reused in different areas of the world. It MAY happen that the original_network_id is the same as the 
network_id of the actual network but this is not the rule. Usually, network_ids are reused between countries using a 
pattern of colours. For specific cable networks, the same network_ids can be reused several times within a same 
country. 

For satellite (and so for hybrid), the original_network_id corresponds to source of the TS and should be associated to 
the infrastructure of the service operator - typically some form of IP encapsulator, SPP and ESG infrastructure - that 
MUST be located in some specific country. If this is the case, the original_network_id of the TS sent over the HF does 
not follow the national country basis since the TS can be sent over different countries, but rather the continental basis. 
The original_network_id of the TS sent over the NHF could follow the same logic as HF but this is not a strong 
requirement: we could envisage having "local" to a specific country original_network_id, then falling into the usual 
geographical distinction relevant for the terrestrial original network id. 

However for the satellite (and so for hybrid), the network_id on his side MUST be uniquely allocated on a worldwide 
basis within a pool of 8 192 (0x0001 to 0x2000) possible values references as "unique satellite" with [i.6] chapter 
table 2. The proposition is to allocate one network_id per spot beam so that the network_id will enable to discover over 
which satellite spot beam the signal is received. The same applies for the repeated signal for which it is also suggested 
to use the same network_id so that the network_id clearly references the infrastructure used to convey the signal, be it 
satellite (SC) or terrestrial (CGC). 

To summarize for the DVB-SH: 

• Original_network_id references the "service" source; the scope can be continental (HF) or national (NHF); 
value MUST be allocated in the table 1 of [i.6] among the 65 535 possible values. 

• Network_id references the "network" used to distribute the information, including satellite beam and terrestrial 
repeating infrastructure; value MUST be taken within the 8 192 values reserved for the satellite on a 
worldwide basis. 
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4.3 Transport Stream (TS) ID 



From the point of view of the DVB -SI specification a network is simply "collection of MPEG-2 Transport Stream (TS) 
multiplexes transmitted on a single delivery system", with no mentioning of requirements for emission in all cells of the 
network. From the point of view of [1] and [2] there are therefore no particular rules whether a TS needs to be broadcast 
in all cells of a network. It is perfectly in line with [1] and [2] to have e.g. a nationwide network with a number of 
regional TSs, each with unique transport_stream_id and content. 

In the DVB-SH case however (see [12] and [i.7]), the TS within an original network MAY be transmitted on all the 
cells of the DVB-SH network, partially or completely (this is the case of the TS sent over HF that is sent over the 
satellite national cell matching with the beam and that has to be repeated on all the local cells of the same network) or 
not (this is the case of the terrestrial TS that are transmitted over a selection of particular terrestrial cells only). 

4.4 DVB service_id 

The DVB-SH [13] introduces the concept of DVB-SH services that enables to create logical partitions of the TS for a 
purpose of content localization in specific modes. The signalling of the DVB-SH service is done at the physical layer so 
that transmitters can determine which content needs to be modulated and where. For the mobility purpose, the DVB-SH 
services are completely superseded by the DVB services: only the DVB services are used in mobility conditions 
according to the following logic: 

• All the DVB services present in the TS are listed by one SDT sub_table. 

• For each DVB service, the SDT sub_table gives: 

a) Data broadcast descriptor: it specifies DATA encapsulated using specific MPE for DVB-SH (see [11]). 

b) In case the NIT signals a paTS, there is possibly a service_availability_descriptor that specifies on which 
cell_id the DVB service is actually present. This enables the terminal to quickly identify if a content is 
present in one particular cell. When service_availability_descriptor is not present for that service, it 
means that the service is present on all the cells transmitting the TS (general availability, like for the 
GC). If the service_availability_descriptor is present, the cells where the service is present (or not 
present) are listed. 

4.5 Rules of Uniqueness 
4.5.1 Original_network_id 

The original_network_id uniquely identifies the source of the TS and this is in relation with the service infrastructure 
itself. Following cases are possible: 

• There could be several sources in the DVB-SH system, so different original_network_ids could be found in the 
DVB-SH network. 

• The same source could be distributed over different DVB-SH networks so the same original_network_id could 
span several DVB-SH networks. 

• The original network could serve a national or continental area. 

For all these reasons, there is a need for uniqueness and the original_network_id is allocated to the source with a global 
scope and references in [i.6], table 1. 
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4.5.2 Platform id 



The IP platform enables to identify the IP flows uniquely through the use of a common range of addresses. The IP 
platform is related to the application infrastructure (video encoders and data servers). There is no need to have only 1 IP 
platform, several can coexist in the DVB-SH infrastructure, in which case several INT would be generated. For 
instance, there could be one IP platform for the global content and one for the local content. Additionally, the IP 
platform can span over several networks which would be the case for instance for a network operator delivering 
services over different spot beams, or a network operator delivering simultaneous services over DVB-H and a DVB-SH 
networks. 

4.5.3 Cell_id 

In the definition found in [4], it is noted in clause 3.1 that "the cell_id that is used to uniquely identify a cell shall be 
unique within each original_network_id" . This scope is fully compatible with handover mechanisms within a country 
having a coherent allocation of original_network_ids. However, ambiguity can arise in DVB-SH since 
original_network_ids do not follow country border as explained in clause 4: it is then highly likely that same cell_id 
could be reused at the border or even within the same country. This would make the cell_id information less relevant for 
handover and could lead to lengthier handover procedures or, what is even worse, handover failures. All these 
limitations could be fixed if the scope was stricter, for instance fixing the scope over a complete satellite system. 

So it is proposed in DVB-SH, that cell_ids shall be made unique throughout all the DVB-SH infrastructure, this being 
true for all cells including the satellite beams. Numbering is done on a 16 bits basis enabling 65 536 cells. However, 
first 256 values (coded over 8 bits) are reserved for satellite beams according to [14]. 

4.5.4 Network_id 

In DVB-SH the network_id is matching a satellite beam and is also unique with a global scope as the value is taken 
from the "unique satellite network ID" range. All infrastructure related to this beam (satellite transponder, terrestrial 
repeater) shall have the same network_id. 

4.5.5 Transport_stream_id 

A TS can be uniquely referenced through the path original_network_id/transport_stream_id [i.5]. In other words, a 
transport stream is unique in the scope of an original_network_id. 

4.5.6 DVB service_id 

DVB service_id is scoped by the TS that is transporting the service. The DVB service_id SHALL be scoped by the 
transport_stream_id and original_network_id. 

4.6 Handover concepts 

The basic mechanism for services access within IPDC over DVB-SH is the following, in 5/6 steps: 

1) use the IP address for the service as provided by the ESG, received via the normal ESG bootstrap procedure; 

2) via the INT find the global path(s) (5-uplet) {original_network_id, network_id, transport_stream_id, 
service_id, component_tag} for each IP stream corresponding to the target IP flow; 

3) via the NIT find the cells and frequencies where the TS can be found; 

4) for those TS that support paTS - as signalled by the NIT - , check via the SDT service_availability descriptor 
on which cell the relevant DVB service can be found; 

5) via the cell_id signalled on TPS and SF, discover most appropriate signal in the terminal neighbourhood; 

6) PSI tables (PAT, PMT) enable to find the PID on the relevant TS. 



ETSI 



1 7 ETSI TS 1 02 61 1 -2 V1 .1 .1 (2009-04) 

One could imagine, that, in the case the triplet {original_network_id / transport_stream_id / service_id} is identical, 
handover between network_ids would be more easily done without using this mechanism but there are several reasons 
why such a simplified handover approach relying on transport_stream_id and/or service_id would not in general work: 

• In general a service_id MAY contain several component_tags, with one elementary stream on each. Knowing 
just the service_id is not sufficient to find the IPDC service. 

• The service_id MAY even be different even if the transport_stream_id is same in paTS case. 
This 5/6 steps mechanism is so assumed to be used in the remaining document. 



4.7 TPS mobility support 



Details on the TPS data used required for handover support with IP Datacast MAY be found in [i.2] and [i.7], 
clause 4.2.8.6. In addition to the TPS, the DVB-SH also provides information via the SF introduced in [13]. 

4.8 Data loss avoidance 

Details on avoiding data loss when performing handovers MAY be found in [i.7], clause 6. 

5 Handover use cases 

5.1 Introduction 

We recall that handover is related to the seamless reception of the same IP flow when some parameters are changing. 
Are not considered under this definition: 

• the change of an IP flow as happens when we zap to a flow belonging to another IP platform; 

• the roaming between IP platforms or two ESG/SPP providers. 

In this clause we focus on the exhaustive review of all possible handovers. For the review of detailed physical 
configurations, please refer to [i.7] clause 5. The presentation has the following logic, splitting cases between 
intra-technology handover and inter-technology handover: 

• SFN intra-handover (clause 5.2). 

• Non SFN intra-handover (clause 5.3). 

• An example of network change, DVB-H / DVB-SH handover (clause 5.4). 

Selection of the SFN or non SFN handover procedure is done by reading the delivery_system_descriptor of the 
destination TS in the NIT: 

• when this is a terrestrial or a hybrid_delivery_system_descriptor without paTS the procedure is the SFN one; 

• when this is a hybrid_delivery_system_descriptor with a paTS, then the procedure MUST be the non SFN one. 
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Is destination TS 

a hybrid_delivery_network 

supporting paTS ? 





Figure 3: Selection of SFN/non SFN scenarios 



5.2 



SFN intra handover use cases 



5.2.1 SFN handover use cases 

The scenarios are enumerated based on the possible identifier variations. Table 5-1 describes the mobility scenarios for 
a terminal acquiring IP flows from a unique IP platform. Each handover use case requires the terminal to apply a 
strategy to maintain, whenever possible, service continuity (i.e. no user perceivable interruption of the IPDC service 
being consumed). 

Table 5-1 : Handover use cases 



Case 


Original 
Network 

ID 
change 


Transport 

Stream ID 

change 


Network 

ID 
change 


Cell/ 
Sub-cell 

ID 
change 


Handover based 

on 

TPS and NIT 


Handover based on 
INT, TPS, NIT, 













N/A 


N/A 


1 








X 


Applicable 


N/A 


2 






X 


X 


Applicable 


N/A 


3 




X 




X 


Not applicable 


Applicable under condition (I) 


4 




X 


X 


X 


Not applicable 


Applicable under conditions 
(I) to (II) 


5 


X 


X 


X 


X 


Not applicable 


Applicable under conditions 
(I) to (II) 


6 


X 


X 




X 


Not applicable 


Applicable under condition (I) 



Condition (I): Target NIT is available (by NIT_other or other means). 

Condition (II): The INT announces IPDC services on other networks. 

Case 0: the terminal moves to/from a satellite-only coverage to a CGC coverage inside the same satellite beam SFN 
cell; modulation is kept (OFDM), cell_id is strictly the same and equal to the satellite cell_id. For the terminal, this is 
not really a handover since there is no perceivable modification of any signalling parameters, only the received power 
will be improved (C/N for instance) or the used antenna MAY differ if two specific antennas are used for satellite and 
terrestrial reception. 

Case 1: the terminal moves between two CGC cells while all other parameters are the same (in particular, 
transport_stream_id is kept the same, TS1). This usually happens when the frequency is changed between the two cells 
and the terminal has to tune to the target frequency. The NIT provides enough information on the availability of the TS 
on adjacent cells and their frequencies so that the terminal is able, by scanning the TPS, to discover the cell_id of the 
target cell. 
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Case 2: the terminal moves between one satellite cell and a CGC cell while keeping transport_stream_id but changing 
network_id. In the DVB-SH case this implies also a change of spot beam because network_ids are related to a satellite 
beam. So this scenario is typical of a country borders crossing but, due to spot beam approximate country borders 
delineation, the transition MAY also occur within a country. There is no complex operation since the TS is maintained. 

Case 3: the terminal moves from one to another CGC cell while changing the TS but keeping other parameters the 
same. This is a typical MFN scenario where handover MUST be ensured seamlessly through adequate mechanism 
(example: phase shifting). In this case, the INT of the target TS MUST be available. This requires also to pre receive the 
service information to be able to quickly derive the PID of the destination. 

Case 4: the terminal moves between 2 cells while keeping original_network_id but changing transport_stream_id and 
network_id. This can happen when crossing the border between two countries or, due to the approximate shape of the 
beam, within a country and implies a change of network_id) since the network_ids are related to the country. In this 
case the INT is needed and MUST be signalled for both networks. Also the target NIT MUST be delivered (via 
NIT_other). 

Case 5: the terminal moves between two spot beams and changes everything (original_network_id, 
transport_stream_id, network_id). This happens when the user moves between two countries having different spot 
beams but some content in common. 

Case 6: the terminal moves between two cells within the same network and receives content from different 
original_network_id and so different transport_stream_id. This happens because original_network_id can span several 
countries (especially those related to satellite operators). This case is similar to the case 5 in the processing. 




— ► addressed in "IPDC over DVB-H Phase 1 - Implementation Guidelines for Mobility" 
----► addressed in this document 

[editor's note: Cell 2 is a satellite cell or CGC cell depending on the use case] 

Figure 4: Handover use cases for SFN 

5.2.2 Detection of alternative service reception parameters 
5.2.2.1 Use Case 1 : Change of Cell or Sub-cell ID 

This scenario is similar in processing to IPDC over DVB-H handover scenario detailed in [4] "Use Case 1: Change of 
Cell or Sub-cell ID". 



5.2.2.2 



Use Case 2: Change of Cell ID and Network ID 



This scenario is similar in processing to IPDC over DVB-H handover scenario detailed in [4] "Use Case 2: Change of 
Cell ID and Network ID". 
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5.2.2.3 Use Case 3: Change of Cell ID and Transport Stream ID 

This scenario is similar in processing to IPDC over DVB-H handover scenario detailed in [4] "Use Case 3: Change of 
Cell ID and Transport Stream ID". 



5.2.2.4 Use Case 4: Change of Cell ID and Network ID and Transport Stream ID 



This scenario is similar in processing to IPDC over DVB-H handover scenario detailed in [4] "Use Case 4: Change of 
Cell ID and Network ID and Transport Stream ID". 



5.2.2.5 Use Case 5: Change of Cell ID and Network ID and Transport Stream ID and 

Original Network ID 



This scenario is similar in processing to IPDC over DVB-H handover scenario detailed in [4] "Use Case 5: Change of 
Original Network ID". 



5.2.2.6 Use Case 6: Change of Cell ID, Transport Stream ID and Original Network ID 

In this scenario, the terminal could find the same IP flow in another TS from the INT sub-table (i.e. as part of the same 
IP platform), and corresponding reception parameters in NIT(actual): 

i) The terminal could find each TS that carries the same IP flow by decoding the IP/MAC 
stream_location_descriptor in the INT sub-table. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs by decoding the 
cell_frequency_link_descriptor in NIT(actual). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor in NIT(actual). 

Based on this, the terminal could check the availability of the signals of the cells accessible where the terminal is 
located and select the ones with the best quality as candidates to handover to. 
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Figure 5: Handover scenario 6 
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INT 

platform_id: 1 

IP/MAC_platform_name_descr() 
IP/MAC_platform_provider_name_descr() 



target_IP_address_descriptor() 



IP/MAC_stream_location_descriptor() 



network_id: 2 
original_network_id: 1 
transport_stream_id: 1 
service_id: 1 
component_tag 



IP/MAC_stream_location_descriptor() 



network_id: 2 
original_network_id: 2 
transport_stream_id: 3 
service_id: 1 
component_tag 



NIT (actual) 

network_id: 2 
cell_list_descriptor() 



cell id: 3 



cell id: 6 



transport_stream_id: 1 
original_network_id: 1 



hybrid_delivery_system_descr() 



cell_frequency_link_descriptor() 



cell id: 3 



transport_stream_id: 3 
original_network_id: 2 



hybrid_delivery_system_descr() 



cell_frequency_link_descriptor() 



cell id: 6 



origin 



-> target 



Figure 6: PSI/SI support for handover scenario 6 



5.3 



Non SFN intra-handover case 



5.3.1 Non SFN handover use cases 

Table 5-2 describes the mobility scenarios. In some cases, the variation of one particular parameter does not impact the 
terminal procedure. Crosses in brackets mean that the parameter could change but this does not affect the terminal 
procedure. 

Table 5-2: Handover use cases 



Case 


Original 
Network 

ID 
change 


Transpor 
t Stream 

ID 
change 


Networ 

kID 
change 


DVB 
service 
change 


Cell/ 
Sub-cell 

ID 
change 


Handover based on 
TPS/SF, NIT, SDT 


Handover based on 
TPS/SF, NIT, SDT, INT 


1 










X 


Applicable under condition 
(V) 


N/A 


V 








X 


X 


Not applicable 


Applicable with 
(IV) (V) 


2 






X 




X 


Applicable under 

conditions 

(I) (V) 


N/A 


2' 






X 


X 


X 


Not applicable 


Applicable under conditions 
(I) (IV) (V) 


3 




X 




[X] 


X 


Not applicable 


Applicable under conditions 
(III) (IV) (V) (VI) 


4 




X 


X 


[X] 


X 


Not applicable 


Applicable under conditions 
(I) (ID (IN) (IV) (V) (VI) 


5 


X 


X 


[X] 


[X] 


X 


Not applicable 


Applicable under conditions 
(I) (ID (IN) (IV) (V) (VI) 



Condition (I): NIT(other) announces the target network. 

Condition (II): INT announces IPDC services on neighbour networks. 
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Condition (III): INT announces IPDC services on neighbour TS. 
Condition (IV): INT announces IPDC services on all DVB services of actual TS. 
Condition (V): SDT(actual) announces the availability of relevant DVB service on target cell. 
Condition (VI): SDT(other) announces the availability of relevant DVB service on target TS. 




Figure 7: Handover use cases for non SFN 

For correctly interpreting the figure: 

• IP flow 1, 2, 3: they represent 3 set of IP flows belonging to the same IP platform; a common IP flow in the 
form of equal or different IP stream(s) MUST be received at both sides of one arrow to ensure seamless 
handover. In order to ease the reading, the transmitted IP flows are also presented on the modulated signal 
where the handover arrows are connected. 

• Colours of the arrows represent the nature of the content (so of a group of IP streams). A blue line represents 
an IP stream of GC nature sent on a HF whereas a yellow line represents an IP stream of LC nature on HF 
(also NHF could be envisaged but is not represented here). 

• Colours of the cells correspond to the frequency used by the multiplex. To ensure repeating of the TDM signal 
using OFDM, another frequency is required; this is the reason why no terrestrial cell within a specific satellite 
beam uses the same colour as the satellite beam one; for instance SI does not have the same colour as Tl, T2, 
T3 and T4. However, a frequency used by one terrestrial cell can be reused by another terrestrial frequency; 
for instance Tl and T3 use same frequency. Also the satellite frequency can be reused in another terrestrial cell 
belonging to another satellite beam, for instance T2 reuses the same frequency as S2. Ultimately, two non 
adjacent satellite beams could also use the same frequency. 

Case 1: terminal receives IP flow 1 and moves to an adjacent cell where the same IP flow is present on the same TS. 

Depending on the case: 

• the IP flow could be GC or LC (both cases are presented on the figure); 

• (Case 1') in the case of local LC, the DVB service_id could be different (it is always the same for GC; in the 
example given on the figure, the IP flow is a GC so same DVB service_id). 
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Case 2: the terminal receives IP flow 2 and moves to an adjacent cell belonging to another network where the same 
flow can be found on the same transport_stream_id having same original_network_id. 

This case happens: 

• inside DVB-SH at the border of a country because network_ids are related to spot beams that usually fit a 
country coverage (case presented on the figure); 

• between two broadcast networks of the same country like DVB-H and DVB-SH. 
Depending on the case: 

• this IP flow MAY be a GC or a LC (on the figure, the IP flow is GC on S2 but LC on SI); 

• (Case 2') in the case of local LC, the DVB service_id could be different (it is always the same for GC; in the 
example given on the figure, the IP flow is a GC so same DVB service_id). 

Case 3: terminal receives IP flow 1 on a CGC cell and moves to an adjacent CGC cell where the same IP flow can be 
found on a different transport_stream_id with same original_transport_stream_id. This is a typical MFN scenario where 
handover MUST be ensured seamlessly through adequate mechanism (phase shifting) in order to receive IP flow 1 
without any interruption. 

Case 4: the terminal receives IP flow 2 and moves to an adjacent cell belonging to another network where the same 
flow can be found on another TS having same original_network_id. 

This case happens: 

• inside DVB-SH at the border of a country because network_ids are related to spot beams that usually fit a 
country coverage (case presented on the figure); 

• between two broadcast networks of the same country like DVB-H and DVB-SH. 
Depending on the case: 

• this IP flow MAY be a GC or a LC. 

Case 5: the terminal receives IP flow 3 and moves to an adjacent cell where the same flow can be found on another TS 
having a different original_network_id. 

Depending on the case: 

• this IP flow MAY be a GC or a LC (LC in the case presented on the figure); 

• network_id MAY be maintained (as displayed on the figure) or not. 

5.3.2 Detection of alternative service reception parameters 

In all cases, the parsing of SDT is described in details in [14]. 

5.3.2.1 Use Cases 1,1': Change of Cell or Sub-cell ID, optional change of DVB 

service ID 

This scenario is similar in processing to [4] "Use Case 1: Change of Cell or Sub-cell ID except an additional check that 
the same service is available on target cell MUST be done since, due to the service_availability usage, same service 
could be present on one but not on the other cell. 

Use Case 1 (no change of DVB service ID) 

First, the alternative services reception parameters could be found in the NIT (actual) and stored by the terminal as 
follows: 

i) The terminal could acquire information on all other frequencies and their cell (sub cell) ids by decoding the 
cell_frequency_link_descriptor that follows the hybrid_delivery_system_descriptor. 
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ii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor. 

Second, the terminal was able to parse the list of DVB services using the SDT as follows: 

i) The terminal parses the SDT (actual) and lists all available DVB services carried by the actual TS. 

ii) The terminal checks in which cells the DVB services are available using the service_availability_descriptor: 

a) If the DVB service is on the target cell, the terminal performs the handover on this cell and the procedure 
ends successfully. 

b) If the DVB service is not present on the target cell, the terminal needs to investigate if there is another 
service where another stream transports the same IP flow and the procedure goes on with the third step. 

Use Case V (change of DVB service ID), extending Use Case 1 

Third, the terminal was able to parse the INT in order to obtain information on the IP flow it is interested as follows: 

i) The terminal parses the INT of its IP platform looking for its IP flow. 

ii) The terminal looks up in matching target_IP_address/slash_descriptor the 
IP/MAC_stream_location_descriptors the list of available IP streams. 

iii) The terminal locates another IP stream in another DVB service present on target cell. 

Based on this, the terminal could check the availability of the DVB service to which the desired IP stream belongs in 
the cells where the terminal is and where terminal could make the handover. 

NOTE: If the IP flow belongs to GC, it is repeated on all cells using the same service_id and there is no change of 
service_id. However, this could be different for an IP flow belonging to LC. If the DVB service_ids are 
different, the handover means that the IP flow will be present in two IP streams within the same TS, one 
IP stream for each DVB service. So the IP flow is sent duplicated on the TS. We give in the following 
figure an example of such a handover where two DVB service_ids are used. 
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Figure 8: Handover use case 1 
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5.3.2.2 Use Cases 2, 2': Change of Cell ID and Network ID, optional change of DVB 

service ID 



This scenario is similar in processing to [4] "Use Case 2: Change of Cell ID and Network ID" except an additional 
check MUST be done on availability of service is available on both source and target cells since, due to the 
service_availability usage, same service could be present on one but not on the other cell. 

Use Case 2 (no change of DVB service ID) 

First, the terminal could determine other networks in which the same TS is available: 

i) The other TS has the same transport_stream_id and original_network_id as the original one. 

ii) Their corresponding reception parameters could be derived from the NIT(other): the terminal finds the 
modulation parameters in the hybrid_delivery_system_descriptor and related frequencies from the 
cell_frequency_link_descriptor in the NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor from NIT(other). 

Second, the terminal was able to parse the list of DVB services using the SDT as follows: 

i) The terminal parses the SDT (actual) sub-table describing the actual TS and lists all available DVB services. 

ii) The terminal checks in which cells the DVB services are available using the service_availability_descriptor. 

a) If the DVB service is on the target cell, the terminal performs the handover on this cell and the 
procedures ends successfully. 

b) If the DVB service is not present on the target cell, the terminal needs to investigate if there is another 
service where another stream transports the same IP flow and the procedures goes on with step 3. 

Use Case 2' (change of DVB service ID), extending Use Case 2 

Third, the terminal was able to parse the INT in order to obtain information on the IP flow it is interested as follows: 

i) The terminal parses the INT of its IP platform looking for its IP flow. 

ii) The terminal looks up in matching target_IP_address/slash_descriptor the 
IP/MAC_stream_location_descriptors the list of available IP streams. 

iii) The terminal locates another IP stream in another DVB service present on target cell. 

Based on this, the terminal could check the availability of the DVB service to which the desired IP stream belongs in 
the cells where the terminal is and where terminal could make the handover. 

NOTE: Handover on an IP flow belonging to GC is necessarily on the same service_id whereas this is not the 
case for an IP flow of LC nature. Local content present in different DVB service_ids and subject of the 
handover is necessarily duplicated at IP streams level (same IP flow, 2 IP streams in 2 DVB services). 
This more complicated scenario is presented in the following figure. 
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5.3.2.3 



Figure 9: Handover use case 2 



Use Case 3: Change of Cell ID and Transport Stream ID 



This scenario is similar in processing to scenario detailed in [4] "Use Case 3: Change of Cell ID and Transport Stream 
ID", except for the additional check of the DVB service availability. Note that this scenario does not concern any GC: 

i) The terminal could find each TS that carries the same IP flow by decoding the IP/MAC 

stream_location_descriptor in the INT sub-table. This descriptor in particular gives the path 
original_network_id, network_id, transport_stream_id, DVB service_id, component_tag: the same IP flow 
could be found on another TS on an adjacent cell. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs by decoding the 
cell_frequency_link_descriptor in NIT(actual). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor in NIT(actual). 

iv) The terminal was able to parse the list of DVB services using the SDT(other) as follows: the terminal parses 
the SDT (other) sub-table describing the TS and lists all available DVB services. The terminal checks in which 
cells the DVB services are available using the service_availability_descriptor. 

Based on this, the terminal could check the availability of the signals of the cells accessible where the terminal is 
located and select the ones with the best quality as candidates to handover to. 
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Figure 10: Handover use case 3 



Use Case 4: Change of Cell ID and Network ID and Transport Stream ID 



This scenario is similar in processing to scenario detailed in [4] "Use Case 4: Change of Cell ID, network ID, Transport 
Stream ID", except for the additional checking of DVB service availability: 

i) The terminal could find each TS that carries the same IP flow from the IP/MAC stream_location_descriptor in 
the INT sub-table, giving the path original_network_id, network_id, transport_stream_id, DVB service_id, 
component_tag: the same IP flow could be found on another TS on an adjacent cell of another network. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs from the 
cell_frequency_link_descriptor in NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor in NIT(other). 

iv) The terminal was able to parse the list of DVB services using the SDT(other) as follows: the terminal parses 
the SDT (other) sub-table describing the TS and lists all available DVB services. The terminal checks in which 
cells the DVB services are available using the service_availability_descriptor. 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to 
another network and select the one with the best quality. 
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5.3.2.5 



Figure 1 1 : Handover use case 4 

Use Case 5: Change of Cell ID, original network ID, TS ID, optional change 
of network ID 



This scenario is similar in processing to scenario detailed in [4] "Use Case 5: Change of Cell ID, network ID, Transport 
Stream ID, original network ID", except for the additional check of the DVB service availability and the possible 
change of network: 

i) The terminal could find each TS that carries the same IP flow by decoding the IP/MAC 

stream_location_descriptor in the INT sub-table, giving the path original_network_id, network_id, 
transport_stream_id, DVB service_id, component_tag: the same IP flow could be found in another TS with a 
different original_network_id, possibly on another network. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs by decoding the 
cell_frequency_link_descriptor in NIT(actual) or NIT(other) depending if the TS belongs to the same or to a 
different network. 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 

location of the current cell by decoding the cell_list_descriptor in NIT(actual) or NIT(other) depending if the 
TS belongs to the same or to a different network. 

iv) The terminal was able to parse the list of DVB services using the SDT(other) as follows: the terminal parses 
the SDT (other) sub-table describing the TS and lists all available DVB services. The terminal checks in which 
cells the DVB services are available using the service_availability_descriptor. 

Based on this, the terminal could check the availability of the signals of the cells accessible where the terminal is 
located and select the ones with the best quality as candidates to handover to. 

The example given in the figure below relates to a change of network_id. 
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Figure 12: Handover use case 5 



5.4 Handover between networks of different access type 
5.4.1 Applicable handover procedures 

From a PSI/SI perspective, handovers between two DVB IPDC networks of different access type (DVB-SH SFN, 
DVB-SH non-SFN, DVB-H) are performed identically to handovers between two DVB IPDC networks of same access 
type. In both cases, the handover procedures to be used are those defined for a handover between two networks of same 
access type (and involving a change of network_id). These "intra- technology" handover procedures have been defined 
in [4] and in clauses 5. 2. and 5.3 of the present document, for respectively DVB-H, DVB-SH SFN, and DVB-SH non 
SFN configurations. 

For a handover between two networks of different access type, the intra-technology handover procedure to be used 
depends on the type of target network, and not on the type of actual network. This procedure can be selected as follows: 

• First, the terminal identifies the type of target network (DVB-SH SFN or DVB-SH non-SFN or DVB-H) by 
decoding the delivery system descriptor of the target Transport Stream in NIT(other). 

• Second, the terminal selects among the procedures of handover between two networks of type of target 
network, the procedure covering the same transition case (change of cell_id and network_id, eventual change 
of original_network_id and/or transport_stream_id and/or service_id). 

Example: for a handover from a DVB-SH network (in whatever configuration) to a DVB-H network, with the transition 
case "Change of Cell ID and Network ID", the applicable procedure will be "Change of Cell ID and Network ID" 
defined in [4] for a handover between two DVB-H IPDC networks. 

Table below indicates which intra-technology handover procedure applies for each case of handover between DVB 
IPDC networks of different type. 
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Table 5-3 



Intra-tech 
applicable 
procedure 


Original 
Network 

ID 
change 


Transport 

Stream ID 

change 


Network 

ID 
change 


DVB 
service 
change 


Cell/Sub 
-cell ID 
change 


Network access 
type 


Comments 


Actual _ "* , 
Target 


[4] 
Use 
Case 2 






X 




X 


DVB- 
SH 
SFN 
DVB- 
SH non 
SFN 


DVB-H 


To be used: intra DVB-H 

IPDC handover procedures 

involving a network_id 

change. 

Target delivery system 

described by a 

terrestrial_delivery_system 

descriptor. 


[4] 
Use 
Case 4 




X 


X 


X 


X 


[4] 
Use 
Case 5 


X 


X 


X 


X 


X 


[5.2.2.2] 
Use 
Case 2 






X 




X 


DVB-H 
DVB-S 
H non 
SFN 


DVB- 
SHSFN 


To be used: intra DVB-SH 
(SFN) IPDC handover 
procedures involving a 
network_id change. 
Target delivery system 
described by a 
hybrid_delivery_system 
descriptor. 


[5.2.2.4] 
Use 
Case 4 




X 


X 


X 


X 


[5.2.2.5] 
Use 
Case 5 


X 


X 


X 


X 


X 


[5.3.2.2] 
Use 
Case 2 






X 




X 


DVB-H 
DVB- 
SH 
SFN 


DVB- 
SH non 
SFN 


To be used: intra DVB-SH 
(non-SFN) IPDC handover 
procedures involving a 
network_id change. They all 
include a service availability 
check on the target cell. 
Target delivery system 
described by a 
hybrid_delivery_system 
descriptor. 


[5.3.2.2] 
Use 
Case 2' 






X 


X 


X 


[5.3.2.4] 
Use 
Case 4 




X 


X 


X 


X 


[5.3.2.5] 
Use 
Case 5 


X 


X 


X 


X 


X 



5.4.2 Examples of handovers from DVB-H to DVB-SH non SFN 

This clause illustrates some cases of IPDC handovers from a DVB-H to a DVB-SH network in non SFN configuration. 
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Figure 13: Some cases of handover from DVB-H to DVB-SH non SFN 

Case 1: the terminal receives IP flow 1 on a DVB-H cell and goes out of reach of the terrestrial DVB-H network. It 
decides to move to a DVB-SH satellite cell where the same IP flow can be found on another TS having same 
original_network_id. 

Case 2: the terminal receives IP flows 1 and 3 on a DVB-H cell and goes out of reach of the DVB-H terrestrial 
network. It decides to move to a DVB-SH CGC cell where the same IP flows can be found on another TS having same 
original_network_id. 

Case 3: the terminal receives IP flows 1 and 3 on a DVB-H cell and goes out of reach of the terrestrial DVB-H 
network. It decides to move to a DVB-SH CGC cell where the same IP flows are present on the same TS. 

5.4.2.1 Example Scenario 2: Change of Cell ID and Network ID and 
Transport Stream ID 

This example scenario illustrates the handover procedure from a DVB-H network to a DVB-SH network in the situation 
when the Transport Stream changes (change of transport_stream_id). The detailed procedure is as follows: 

i) From the IP/MAC stream_location_descriptors of the INT sub-table, the terminal could determine that the 
same IP flows are carried by DVB services on another Transport Stream in another network. 

ii) From the NIT_other sub-table describing this network, the terminal could acquire the 

hybrid_delivery_system_descriptor as well as the cell_frequency_link_descriptor characterizing this other 
Transport Stream in this other network. 

iii) Using the service availability procedure specified in [14], the terminal could determine on which cells listed by 
this cell_frequency_link_descriptor the DVB services are actually available. 

iv) From the cell_frequency_link_descriptor, the terminal could acquire information on the frequencies of such 
cells. 

v) From the same NIT_other sub-table, the terminal could acquire information on the geographical location of 
such cells. 
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Based on this, the terminal could check the frequencies carrying the other TS in the neighbouring cells belonging to the 
other network and select the one with the best quality. 



INT 



platform_id: 1 



IP/MAC_platform_name_descr() 
IP/MAC_platform_provider_name_descr() 



target_IP_address_descriptor() // IP flow 1 



IP/MAC_stream_location_descriptor() 



network_id: 2 
original_network_id: 1 
transport_stream_id: 2 
service_id: 3 
component_tag 



IP/MAC_stream_location_descriptor() 

| network_id: 1 
original_network_id: 1 
transport_stream_id: 1 
service_id: 1 
component_tag 



target_IP_address_descriptor() // IP flow 3 



IP/MAC_stream_location_descriptor() 



network_id: 2 
original_network_id: 1 
transport_stream_id: 2 
service_id: 3 
component_tag 



IP/MAC_stream_location_descriptor() 

network_id: 1 
original_network_id: 1 
transport_stream_id: 1 
service_id: 2 
component_tag 



NIT (actual) 

network id: 2 



cell_list_descriptor() 



cell id: 4 //T4 



transport_stream_id: 2 
original_network_id: 1 
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cell_frequency_link_descriptor() 



cell id: 4 //T4 



NIT (other) 
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cell id: 2 //T2 



cell id: 3 //T3 
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cell_frequency_link_descriptor() 



cell id: 1 //S1 



cell id: 2 //T2 
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actual 



target 
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Figure 14: PSI/SI support for Example Scenario 2 

5.4.2.2 Example Scenario 3: Change of Cell ID and Network ID 

This example scenario illustrates the handover procedure from a DVB-H network to a DVB-SH network in the situation 
when the Transport Stream does not change. The detailed procedure is as follows: 

i) From a previous parsing of INT sub-table, the terminal could cache the service_id of the DVB service carrying 
the IP flows in the actual Transport Stream. 

ii) From NIT(other), the terminal could determine that the actual Transport Stream is also present in another 
network. 

iii) From the NIT_other sub-table describing this network, the terminal could acquire the 

hybrid_delivery_system_descriptor as well as the cell_frequency_link_descriptor characterizing the actual 
Transport Stream in this other network. 

iv) Using the service availability procedure specified in [14], the terminal could determine on which cells listed by 
this cell_frequency_link_descriptor the DVB service is actually available. 

v) From the cell_frequency_link_descriptor, the terminal could acquire information on the frequencies of such 
cells. 
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vi) From the same NiT_other sub-table, the terminal could acquire information on the geographical location of 
such cells. 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to the 
other network and select the one with the best quality. 



NIT (actual) 

network_id: 2 
cell_list_descriptor() 
cell id: 4 1114 



transport_stream_id: 2 
original_network_id: 1 
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cell id: 4 1114 
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Figure 15: PSI/SI support for Example Scenario 3 
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